Individual nodes in a multi-processor computing platform need to be updated periodically, at least due to periodic updates that pertain to an underlying operating system. This can be handled by redeployment of new configurations (e.g., instances) of updated images. A hypervisor or other helper software can be instructed to refresh a configuration (e.g., instance) of a node. In a cluster environment (e.g., having many processors that can be directed by a cluster manager), a cluster manager can instruct all hypervisors running in a cluster to update respective nodes. Accordingly, even a large installation (e.g., many processors, many clusters, etc.) can be updated programmatically (e.g., through installation instructions and/or installation scripts). In some cases hypervisors themselves and any operating system code running under the hypervisor can sometimes also need updates to the respective software base. Legacy boot-strapping of a processor—installing an operating system code base to be executed by the processor—needs at least some support from the hardware and/or BIOS in order to read the operating code from some media (e.g., a CDROM, a DVD, a formatted flash drive, etc.).
Unfortunately, it quickly becomes impractical to use such legacy techniques, at least inasmuch as legacy techniques rely on minimally-functional, hardware-specific busses (e.g., an intelligent platform management interface (IPMI)), and hardware-specific components (e.g., baseboard management controllers (BMCs)) in combination with low-level protocols (e.g., BIOS protocol to boot from an ISO image). Consider an installation that has many processors in a cluster running a first operating system that is to be reconfigured to run a second operating system, plus any hypervisors and/or virtual machines running on the same cluster hardware. Legacy techniques rely heavily on vendor-specific tools when installing operating system images (plus any needed hypervisors and/or virtual machines running on the same cluster hardware), and reliance on such vendor-specific tools is fraught with both hardware- and software-oriented problems. As examples, (1) using IPMI virtual media requires additional cabling and switch capacity that may or may not be available at the location of the cluster to be upgraded; (2) BMCs are notoriously unreliable, resulting in installation failures traced to BMC hang events; and (3) configuring IPMI networking in addition to any needed hypervisor and virtual machine networking is often non-trivial and places a severe burden on the installation manager. What is needed are ways to eliminate or reduce reliance on any external imaging devices (e.g., for hosting an ISO image) while facilitating easy configuration (e.g., that can be performed by end users or system administrators).
Legacy techniques rely heavily on proprietary technologies such as preboot execution environments (e.g., PXE) and/or Linux-specific tools (e.g., DD), and techniques such as to write a spare partition on the boot media, mark it for boot and boot into it are also riddled with vendor-dependencies as well as inter-vendor incompatibilities.
What is needed is a technique or techniques to improve over legacy approaches.